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NASA is initiating a new program to explore the Moon, Mars, and beyond with safe, 
sustainable, and affordable missions. These new exploration missions will require a more 
reliable and flexible communications network than used in today’s science missions to serve 
as the medium for voice, video, and data exchange on the surface. This integrated network 
will enable safety, collaboration, and autonomy to address the emerging requirements of 
remote human exploration. It will span communications links with vastly differing time de- 
lays and intermittent connectivity. For example, local communications links among nearby 
entities on the surface of the Moon will include more unpredictable connectivity, less time 
delay, and more relative node mobility than long range communications between planets 
and moons. These heterogeneous links will coexist in one complex networked system of 
systems architecture. 

Simulation and modeling of surface-based communications networks provides a rapid 
and cost effective means of requirement analysis, protocol assessments, and tradeoff stud- 
ies. Robust testing is especially important for exploration systems, where the cost of 
deployment is high and systems cannot be easily replaced or repaired. However, simula- 
tion of the envisioned exploration networks cannot be achieved using commercial off the 
shelf network simulation software. The surface network environment, which includes a high 
degree surface mobility with changing line-of-sight and unpredictable connectivity, and the 
complexity of the nodes involved differentiates surface simulation from terrestrial simu- 
lation. In addition, models for the nonstandard, non- COTS protocols used aboard space 
systems are not readily available. 

This paper will address the simulation of realistic scenarios representative of the ac- 
tivities which will take place on the surface of the Moon, including selection of candidate 
network architectures, and the development of an integrated simulation tool using OPNET 
modeler capable of faithfully modeling those communications scenarios in the variable delay, 
dynamic surface environments. Scenarios for exploration missions, OPNET development, 
limitations, and simulation results will be provided and discussed. 

I. Introduction 

T he Vision for Space Exploration 1 refocused NASA to a new initiative to explore the solar system with 
safe, sustainable, and affordable missions. To achieve such missions and address the problems encoun- 
tered during human exploration of unknown areas, new systems and technologies are required which can 
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systemmatically extend the human presence in a safe and cost-effective manner. Exploration missions of 
the future will require a more reliable and efficient communications network than used in today’s science 
missions to serve as the medium for voice, video, and data exchange. The network will integrate commu- 
nications, navigation, power, and computing technologies to address the emerging requirements of remote 
human exploration, enabling safety, collaboration, and autonomy. It will span communications links with 
vastly differing time delays, noise levels, interference levels, and intermittent connectivity. For example, 
communications between large assets on the surface of the Moon will include more power, longer distances, 
higher data rates, and less relative node mobility than communications between small, mobile nodes such as 
robots. These heterogeneous links will reside together in one surface network, and that surface network will 
interface seamlessly with the other networks defined in the exploration system of systems. 2 

NASA’s exploration roadmap calls for manned missions to the Lunar surface by 2020. 3 The initial 
missions will be similar to the Apollo missions, with no pre-deployed assets and the capability for landing 
anywhere on the Moon’s surface for a duration of four to seven days. 2 As the exploration capability matures, 
the Lunar missions will be expanded for use as a Mars testbed. An infrastructure consisting of power, in situ 
resource utilization, and communications will be pre-deployed on the surface, and the missions will increase 
in duration to between 42 and 98 days. 2 The surface network will play an integral role in both the early and 
later Lunar missions and Mars missions, enabling collaboration between astronauts and advanced monitoring 
and control capabilities. 

A realistic surface mission might include four astronauts, four robotic assistants, one rover, one habitat, 
and one lander in a 90 day mission. 2 The communications architecture will build upon the success of the 
Mars Exploration Rovers by utilizing satellite relays 3 rather than direct links to Earth to achieve higher 
data rates and lower power consumption. 4 In order to reduce costs, leverage a large talent base of engineers, 
and provide maximum reliability, NASA will assess modified commercial off-the-shelf (COTS) protocols 
and hardware to leverage in the communications system with the goals of modularity, affordability, and 
interoperability. 4 Near-term future missions will use similar technology to that used in today’s missions: 
S-Band links and bent pipe relays, but no advanced network layer protocols. However, Mars missions, long 
duration Lunar missions missions, and a sustained human presence on the Moon may attempt to heavily 
leverage network protocols. 5 

Simulation and modeling of these new and untested communications networks provides a fast, inexpen- 
sive means of assessing mission requirements and performing tradeoff studies and performance assessments 
on critical protocols and network architectures. Robust testing is especially important for space exploration 
systems, where the cost of deployment is high and systems cannot be easily replaced or reconfigured. Sim- 
ulation can be incorporated into all stages of the technology development process. However, simulation of 
the envisioned exploration networks poses challenges which cannot be addressed using commercial off the 
shelf (COTS) network simulation software. The surface network environment, which includes a high de- 
gree surface mobility with changing line-of-sight and unpredictable connectivity, and the complexity of the 
nodes involved make surface simulation unique and different from terrestrial simulation. In addition, the 
nonstandard, non-COTS protocols used aboard space systems are not modeled in COTS network simulators. 

Even with simulation solutions for the problems above, testing of the surface networks remains a problem. 
Because this simulator will be used to test protocols and architectures in the context of a specific environment 
(the Lunar surface), accurate and comprehensive testing scenarios are important to maximize the reliablilty 
of the system when it is deployed. Countless possible testing scenarios exist and it is difficult to predict the 
Lunar infrastructure fifteen years into the future. As a result, an effective simulation tool must be capable 
of evolving to support new technologies and capabilities. 

II. Assumed Surface Communications Requirements 

The surface network will consist of a number of nodes (i.e. anything requiring communications) in- 
terconnected into a network. Nodes might include the habitat, lander, astronauts, rovers, robots, science 
instruments, controls, sensors, and cameras. Nodes will use the surface network to communicate with one 
another. A network architecture provides a high degree of flexibility and scalability to the surface operations 
and, because it can function effectively without a direct link to Earth and minimal human intervention to 
support autonomous and semi- autonomous surface operations. 

The surface network, shown in figure 1 will consist of a number of nodes (i.e., anything requiring commu- 
nications) interconnected into a network. These nodes might include the habitat, lander, astronauts, rovers, 
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Figure 1. Lunar exploration operational communications scenario. 


robots, science instruments, controls, sensors, and cameras. Nodes will use the surface network to commu- 
nicate with one another, and each node needs a diverse application set to achieve its function. The surface 
network must integrate multiple applications with greatly differing requirements and seamlessly interface 
with the terrestrial and in-space networks planned by NASA . 6 Some applications require more bandwidth 
and have different communications durations than others. Some require real-time interaction while others do 
not. Errors and packet loss are tolerable in some streams, but not in others. Streaming video, for example, 
can handle moderate data loss but requires high data rates and minimal variation in delay (i.e., jitter), while 
text e-mails require reliable data delivery with no packet loss but places no constraints on delay or jitter. 

Because exploration capability will be built out gradually into a system of systems, the surface network 
must seamlessly interface with the system of systems elements, which may be built in different time frames 
from the surface systems . 6 The surface network will interface with: the crew transportation system, which 
will transport the crew from Earth to their destination; the ground support system, which will provide the 
ability to manage flight systems, as well as land, recover, refurbish, or dispose of those systems; the in- 
space support system, which will provide mission support from space, including satellite relays; the robotic 
precursor system, which will use robotic technology to provide measurements, technology demonstrations, 
and infrastructure in preparation for human missions; and the cargo delivery system, which will transport 
un-crewed mission elements to their destination , 2 

The crew will likely spend a substantial amount of time operating and maintaining systems during the 
first Lunar missions. As the exploration capability shifts toward long duration Lunar missions and Mars 
missions, that time is expected to decrease as autonomous and semi-autonomous systems are introduced . 7 
Distributed, autonomous communications will be required for Mars missions, when large time delays prohibit 
real-time interactions with Earth. The surface network will provide the ability for autonomous node discovery 
and configuration, as well as autonomous data forwarding. 

The enormous cost of transporting objects into Earth orbit and beyond will play a crucial role in the 
design of exploration missions. To mitigate the high per-pound mission cost, all elements involved in the 
exploration will be minimized with respect to mass and volume. Because of the stringent mass and volume 
constraints, most surface network nodes will not be capable of high-throughput power generation and high 
power communications. Network nodes will therefore require power-efficient components and power-aware 
protocols to enable a high performance, power-efficient exploration system. Alternative methods of reducing 
mass and volume, such as the reduction of cabling through wireless communications and power transfer, will 
increase the dependency of the system on wireless technologies . 8 


3 of 15 


American Institute of Aeronautics and Astronautics 



III. Simulation Tools 


Numerous simulation tools exist which can provide partial simulation of the applications, networking, 
and physical layer which will operate within the surface network. OPNET Modeler, ns- 2, and Qualnet 
are common terrestrial network simulators, which lack some of the protocol support required for surface 
exploration missions. Satellite Tool Kit, HerTZ mapper, ICS telecom, and wWLAN toolbox provide tools 
for physical layer properties which can be used for links within the exploration network, but do not include 
network simulation support. While models for many of the applications for surface networks, such as e-mail 
and voice traffic, are readily available, application models for many applications, such as CFDP and robotic 
control, are not commercially available. No off the shelf simulation tool is capable of complete Lunar surface 
network simulation. 


IV. Scenarios 

Because the surface network, shown in figure 1 is being designed specifically to support exploration, it 
is important to accurately characterize the exploration scenarios under which the network will operate. A 
networking protocol might perform exceptionally in simulations only to fail when deployed because it was not 
tested under the proper conditions. Simulation can play an important role in the communications network 
architecture development process, by providing detailed feedback on proposed infrastructures and systems 
early in the design process. 

However, simulating these communications network architectures also poses significant challenges. Be- 
cause the Lunar exploration missions remain in the pre-planning phases, it is not clear what communications 
nodes and activities they will entail. This can lead to considerable difficulty in development of accurate 
and relevant exploration scenarios for simulation. The simulation framework must possess the flexibility to 
quickly adapt to top level scenario changes with a minimum level of development effort. 

A. Scenario Development Methodology 

NASA’s Exploration Systems Mission Directorate 
has begun to release top level requirements for the 
early (spiral 1) crew transportation system 2 and 
robotic precursor systems. 9 For systems for which 
no official requirements have been released, such 
as the destination surface system, the simulation 
scenarios were synthesized from multiple reliable 
sources of information. NASA has released a num- 
ber of design reference misssions for Lunar and Mar- 
tian exploration, which are used as baselines by 
technology developers and mission planners. They 
represent missions which might be similar to those 
which will be undertaken in the future. Because spi- 
ral 3 long duration Lunar missions will be used as 
a testbed for Mars exploration, it is assumed here 
that most of the surface scenarios in those missions 
will be very similar to Mars missions. The Mars reference missions were therefore used in the development 
of long duration Lunar scenarios. Many of the design reference missions contain numerous commonalities, 
ranging from surface nodes, to in-mission activities, to mission concepts. The nodes and activities used in 
the simulation scenario were based on the design reference missions and on other key documents describing 
potential surface scenarios. 

Once the nodes and activities were determined, more detailed information was obtained on the appli- 
cations and communications required for the full functionality of each node. Nodes were broken down into 
component subsystems and each component was analyzed to assess the properties of the required commu- 
nications. A robot, for example, has numerous components, including a camera, which will require commu- 
nication of streaming video. Design reference missions, mission architecture concept sources were used to 
determine the components for each node, and technical documentation (e.g. terrestrial camera specs, ISS 
voice communications, etc) were used to assess the communications requirements for each component. 
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Figure 3. Lunar surface exploration scenario. 


B. Communications Nodes 

Exploration activities on the Lunar surface will involve a number of operational elements (nodes) which 
will provide the functionality required for safe and productive exploration. Figure 2 shows the operational 
nodes and for Lunar surface communications. Each node and some subsystems within each node will require 
communications with external nodes to achieve intelligent autonomous network operation. These nodes 
include: the Lunar surface access module, habitat, science instruments, rovers, robots, astronauts, and 
pressurized vehicles. 

The Lunar Surface Access Module (LSAM) will provide crew habitation functions on the surface for four 
to six crew members during short stay (3-7 day) Lunar missions. 2 It will also support EVA so that crew 
members can explore and, in long duration missions, transition to the habitat or other pre-deployed assets 
on the surface, 2 The LSAM will include the communications hardware to establish multiple simultaneous 
bidirectional communications links to Earth, orbiting relays, and assets on the surface at both short (<5km) 
and long (<60km) distances. The LSAM design includes the following subsystems: avionics, environmental, 
airlock, vehicle command and control, communications, life support, thermal control, power, propulsion, 
crew accommodations, radiation protection, structures, and mechanisms. 7,10,11 Each of these subsystems 
uses the surface network for interconnection and coordination with other systems and subsystems. 

The Lunar Habitat is a pre-deployed surface habitation and science laboratory unit which provides 
habitation for a crew of four to six for 42-98 days. The habitat serves as a base of operation for EVA 
activities and on-site robotic teleoperation. 12 Like the LSAM, the habitat will include communications 
hardware to establish links to Earth, orbiting relays, and assets on the surface at short and long distances. 
The habitat design includes the following subsystems which coordinate through the surface network: airlock, 
habitat command and control, communications, life support, thermal control, power, crew accommodations, 
radiation protection, structures, and mechanisms. 7,10 

Exploration missions will employ a wide variety of science instruments to record data and analyze samples 
on-site. The science instrument package will include a seismometer, heat flow probe, laser retroflector, mass 
spectrometer, Lunar ejecta and meteorite detector, and interferometer. These instruments will possess the 
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Table 1. Application protocols for the surface exploration network. 


Service 

Type 

Encoding/ Compression 

Transfer Protocol 

Video (Real-time or 
store-forward) 

Constant Rate 

Raw, MPEG, MPEG-2, 
MPEG-4 

RTP, CRTP, CFDP, FTP, 
HTTP, SMTP 

Audio (Real-time or 
store-forward 

Constant Rate 

Raw, DPCM, ADPCM, 
MPEG-3, Ogg, Flac 

RTP, CRTP, CFDP, FTP, 
HTTP, SMTP 

File Transfer 

Reliable 

Zip, gzip, bzip 

CFDP, SMTP, FTP, HTTP, 
NFS, SMB 

Monitoring and Au- 
tomated Controls 

Constant Rate, Control 


CBR (UDP) 

TT&C 

Constant Rate 


CBR (UDP) 

Robotic Command, 
Control, and Collab- 
oration 

Control 

SSL, TLS, blowfish, des, 
3des, arcfou 

CORBA, HTTP, XML 

E-mail (text, audio, 
video) 

Reliable 

ASCII, any file type 

SMTP, POP, IMAP, CFDP 


communications hardware to establish short distance (<2km) surface-to-surface links and, should they be 
left on the surface by the crew, low rate direct to Earth links for science return after the mission has been 
completed. 

Some tasks, such as construction, deployment of assets, and exploration of distant terrain, will be carried 
out by robots. 6 7 These robots will range from teleoperated to autonomous and will contain a number of 
interconnected subsystems, including actuators, sensors, avionics, and power. They will possess the hardware 
to establish multiple simultaneous communications links to Earth, orbiting relays, and surface assets at short 
distances. 

For exploration within a kilometer or two of a pressurized habitat, astronauts will use EVA suits. 7 These 
suits will provide a number of remotely monitored, internally controlled subsystems, including life support 
(oxygen pressure, C02 removal, thermal control, medical support), suit avionics (actuators, sensors, power, 
communications), and informatics (voice, video cameras, video displays, robotic system control). The EVA 
suit will provide the functionality for multiple simultaneous bidirectional communications paths and to assets 
on the surface at short range and to Earth. 

The relatively short traverse range of humans in EVA suits can be augmented by the use of rovers to 
extend the range of exploration. 7 The rover will transport the EVA crews over multi- kilometer distances 
and will also provide nearby exploration assets with network communications to surface assets at short and 
long distances, to orbiting relays, and to Earth. 

The need will arise in long duration missions for human crews to explore beyond the range of an unpres- 
surized rover. To support this capability a pressurized vehicle will be used which can provide simple crew 
habitation support for long duration excursions. 7 It will contain the communications hardware required to 
establish multiple simultaneous bidirectional links to Earth, orbiting relays, and assets on the surface at short 
and long ranges. The pressurized vehicle will also contain a number of subsystems which can be remotely 
monitored and controlled, including personal communication modules, cameras, avionics, computer systems, 
life support, biological sensors, power systems, actuators and drivers, and portable workstations. 

C. Activities 

The tasks and activities which will be performed on the surface will be integral to the communications and 
networking architecture which is required. The exploration and science objectives to be performed on the 
surface can be broken into four categories: field work, telerobotic exploration, laboratory and intravehicular 
activity experiments, and preparation of materials for return to Earth. 7 

Key systems must be connected to the habitat upon landing, and routine inspections and repair will 
be performed on all critical systems. A substantial portion of the crew’s time on the surface will be spent 
maintaining and possibly deploying systems to support exploration. This will require reliable and timely 
delivery of sensor data, and robotic commanding to deploy and pre-deploy assets. High fidelity images and 
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Table 2. Surface exploration network technologies. Technologies used in the simulation are shown in bold 
italics. The technologies selected do not necessarily represent the best possible configuration. 


Service 

Physical Layer 
Data Link Layer 


Network Layer 


Transport Layer 

* 2-60 km 
t 0-2 km 
t <10 m 


Medium Ranged Links Short Ranged Links 


Long Range* Links 
Ka-band, S-band 

CCSDS proximity 1, IEEE 
802.16 (WiMAX), IEEE 
802. 1 lx (Wi-Fi), frame re- 
lay / HDLC, ATM/SONET, 
DVB 

IP (RFC 791), CCSDS 
SCPS-NP, IPv6, AODV, 
DSR, TORA, OSPF, RIP 

UDP, TCP, SCPS-TP 


UHF, S-band 

CCSDS proximity 1 , IEEE 
802 A lx (Wi-Fi) 


IP (RFC 791), CCSDS 
SCPS-NP, IPv6, AODV, 
DSR, TORA, OSPF, RIP 

UDP, TCP, SCPS-TP 


UHF, S-band, copper, fiber 

IEEE 802.3 (ethernet), 
IEEE 802.1 lx (Wi-Fi), IEEE 
802.15 (bluetooth), IEEE 
1394 (Firewire), IEEE 1355 
(spacewire), FDDI, SOIF 

IP (RFC 791), CCSDS 
SCPS-NP, spacecraft bus, 
IPv6, AODV, DSR, TORA, 
OSPF, RIP 

UDP, TCP, SCPS-TP 


video could also be used to perform remote inspection and assessment. In addition, the presence of a crew 
on long duration missions will mandate health and medical operations as well as multimedia recreational 
and training programs to keep the crew in the best possible mental and physical health . 10,13 

Human presence will enable observations in exobiology, geology, and atmosphere to be made in the field. 
This field work will comprise geological observation and experimentation and sample curat ion. Samples and 
data will be collected and returned to the laboratory for analysis, and information will be transmitted to 
scientists on Earth so they can provide input . 7 * Scientists may also have real-time video conferencing with 
astronauts on the surface to coordinate experiments and sample curation . 13 

In order to explore the areas where it is dangerous or impossible for humans to travel, the crew will 
have the ability to operate telerobotic systems in real-time. These systems can be used to transport crew 
members to distant locales not easily accessible on foot or to perform unmanned robotic exploration over 
rough terrain. They will also be used in later missions to prepare and deploy surface infrastructure and 
equipment, including the power plant, in-situ resource utilization plant, and associated systems. This will 
require remote robotic command and control, as well as streaming video and sensor data to provide a rich 
virtual presence . 7, 13 

On-site laboratory experiments will be an integral part of surface missions. Both geological and biological 
experiments will be carried out in a surface-based facility in collaboration with experts on Earth . 13 Samples 
and data may be sent to scientists on Earth for real-time analysis and planning through video conferencing . 7 

1. Applications 

The final crew task will be to select and package samples prior returning to Earth, where the samples will 
be studied in more detail. This may require experimental data to be sent to Earth prior to departure and 
video conferencing so that experts can provide advice on sample packaging. A large portion of this activity 
will involve collaboration with earth-based experts to select the samples which will be returned to Earth 
through video conferencing and exchange of experimental data . 13 

D. Interfaces 

1. Protocols and Networking 

The communications network nodes will interface with one another to enable cooperative and effective 
exploration activities. Applications will define the data which will be exchanged between communications 
endpoints, networking and protocols will ensure that the data is routed and delivered to its destination, and 
hardware and physical layer interfaces will create individual point-to-point wired and wireless links. 
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Nodes on the surface will employ a diverse set of applications to enable highly coordinated and safe 
activities. 14 These include real-time, bidirectional audio and video for conferencing, telemedicine, and recre- 
ation, high quality store- forward video for public outreach, data services for software uploads, e-mail, and 
downloads, and low jitter command for robotic teleoperation. Each major or critical exploration asset will 
use health monitoring and control systems to report its status in real-time, so that problems can be rapidly 
discovered and handled with minimal astronaut intervention. 

The surface network will comprise a suite of protocols capable of reliable, efficient, on-demand, and 
bidirectional data delivery across multiple hops in the harsh Lunar environment. The protocols and network 
architecture used conform to the ISO/OSI model for layered communications and provide services for the 
transport, network, and data link layers. 

In the transport layer, which regulates the end-to-end delivery of data, the User Datagram Protocol 
(UDP) protocol is used to provide simple, best effort data transport. Transport Controf Protocol (TCP) 
was not selected due to its poor performance over high bandwidth, high delay networks. Applications which 
require zero packet loss use the CCSDS File Delivery Protocol 15 application protocol over UDP. 

On the network layer, which manages node addressing and data routing, the IP protocol is selected due 
to its widespread terrestrial use. The AODV mobile ad hoc networking (MANET) protocol was chosen 
to achieve dynamic ad hoc routing, although other protocols such as DSR or TORA could provide similar 
functionality. Routing functionality could also be provided by standard fixed routing protocols, although 
the effectiveness of that approach for surface networks has not been evaluated. 

On the MAC/data link layer, which manages point-to-point communications including media access and 
framing, the protocols selected depend on the link type. Gigabit ethernet was used for all wired links, 
and a customized bent pipe relay protocol was used for space-based links. 802.11 variants were used for 
surface-to-surface links, including 802.11a (54 Mbps), 802.11b (11 Mbps), and 802. llg (54 Mbps). 

2. Hardware and Physical Layer 

Communications hardware on the surface will serve as data conduits, providing links upon which the pro- 
tocols and applications can function. Because small and mobile nodes cannot accomodate communica- 
tions hardware with large power, mass, and volume requirements, the hardware in the surface network 
will be as small, power-efficient, and light weight as possible. Communications hardware will consist of 
digital signal processors, transceivers, and antennas, SEU-tolerant digital signal processors will modu- 
late/demodulate, encode/decode, and convert digital streams to analog RF (and vice versa). Power- efficient, 
wearable transceivers operating in the S-band will provide surface-to-surface transmit and receive capabili- 
ties, while Ka-band transceivers will operate over surface-to-orbit and in-space links. Small omnidirectional 
antennas are assumed for all surface-to-surface links due to their maturity, although developing technologies 
such as smart antennas may provide significant performance enhancement. 

V, Surface Network Simulation 

OPNET Modeler was used to simulate the surface network scenarios described above. The scenario, 
shown in figure 4, was implemented using a layered, hierarchical architecture. Because some of the basic 
capabilities for surface networks were not present in OPNET, tool modifications were performed to achieve 
simulation capability. 

A. Simulation Architecture 

The surface network was designed such that each surface-based entity (e.g. astronaut, habitat, rover, robot), 
was represented by a subnet. An EVA astronaut’s subnet is called out in figure 4. Each host within that 
subnet represented an instrument, subsystem, or sensor, A wireless subnet was also created to contain 
the surface entity subnets and the links to orbiting relays and to Earth. This heirarchical architecture is 
inherently scalable and provides an easy means for the user to hide potentially distracting details. 

B. Tool Modifications 

Several modifications were made to enhance OPNET’s capability to support surface communications net- 
works for exploration. They include the development of the connectivity matrix, bent pipe relay support, 
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Figure 4. Lunar surface exploration scenario implemented in OPNET Modeler. The diagram on the left is 
the main SWLAN view and the diagram on the right is an EVA astronaut’s personal area network. 


CBR application, robotic control application, and reliable file transfer application. 

The Space Communications Architecture called for three types of applications: constant bit rates (CBR), 
robotic control, and reliable file transfer. These applications could have been modeled using the standard 
OPNET Custom Application model, but the decision was put them in a new process model. There are two 
major reasons why this decision was made. First it allowed greater control over the presentation of results. 
Second, it allows delays to be added at the application layer. These delays will impact results without direct 
modeling of parts of the network (such as the backbone). 

1. Connectivity Matrix 

Over the course of routine field exploration, a number of unpredictable, unplanned events and effects induced 
by the surface terrain may occur resulting in signal degredation or loss. Multipath interference, for example, 
might drastically lower signal to noise ratio between two astronauts as they move relative to one another. A 
robot might explore into a cave or crater and completely lose line of sight (and its signal) with base camp. 
In both these cases, the network should be able to compensate for the weak or non-existant signal. 

A connectivity matrix was developed to trigger these link changes from within a simulation. It enables 
the user to arbitrarily assign physical layer properties (line of sight, BER, delay, data rate) to links in surface 
exploration network scenarios. To enable this functionality, one process model and one node model were 
created, and four pipeline stages were modified. The connectivity matrix models can currently affect two 
types of links, satellite links and 802.11 radios. The models affect the two different links in very different 
ways, and the methods used to apply the connectivity matrix for these two links can be used as guide if 
there is a need to use other types of links in the future. 

Node Requirements The connectivity matrix models make use of the standard node attribute, “user id.” 
It is expected that each “user id” value will initially be set to -1. It is advised that every node model that 
is to be used have the “user id” hidden and set to -1 in the Node Interfaces dialog box (The Node Interface 
dialog box can be accessed under the Interfaces pull down menu in the node mode editor). At initialization 
the “user id” will be set on each node by the NASA_Connectivity .Setup process. After initialization pipeline 
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stages will use the “user id” attribute to index the global connectivity matrix. 

Global Connectivity Matrix The global connectivity matrix is a matrix containing connectivity in- 
formation for each pair of nodes. It is assumed that there is only one connection between two nodes, and 
that links are unidirectional - a bidirectional link would be represented by two unidirectional links. The 
global connectivity matrix does not assume, expect, or require symmetry over links. This is intentional to 
allow for asymmetric links, particularly in regards to data rates. This also means that links could have 
asymmetric propagation delay even if this may not be physically possible. This allows for customization 
of link properties based on the hardware being modeled. The following information is contained in each 
connectivity information structure: 

• Time - The time at which this set of information first becomes active. 

• IDs - Transmitter and receiver IDs (also can be attained from array indexes). 

• Connected - Boolean value indicating whether this is currently a valid link. 

• Delay - Propagation delay between two nodes. 

• BER - Bit Error Rate on the link between two nodes. 

• Data Rate - The transmitter data rate for this link. 

The third dimension of the array is used to hold the present and future connectivity information. The 
pipeline stages use the future and current connectivity information to linearly interpolate BER and prop- 
agation delay. If no future connectivity information is available the pipeline stages simply use the current 
BER and propagation delay. If connectivity information for a pair of nodes is never specified, default values 
calculated by Modeler’s pipeline stages are used. 

Setup Process Model The NASA_Connectivity .Setup process model 
sets up the global connectivity matrix for the simulation. There should 
be only one instance of this process model in a scenario, and it is most 
likely located in the in the NASA_Conn_Matrix node model. The global 
connectivity matrix is also declared in this process model. All pipeline 
stages that will use the connectivity matrix should extern it. 

Functionality At the beginning of the simulation, this process reads Fi S ure 5 * The NASA connectiv- 

, nn n i • . . . , ity matrix setup process model, 

m the connectivity input hie specified m the connectivity matrix at- 
tributes. By parsing this file it creates the current connectivity matrix. 

A global event list is also created from the file for future updates for the 

connectivity matrix. This process model will use the event list to schedule self interrupts which trigger events 
to update the connectivity matrix. 

For wired links this process model is responsible for changing the attribute “condition” on the link itself. 
This attribute will turn the link on and off, and its value will be controlled by the connectivity field of the 
connectivity information. All other values will simply be changed in the connectivity matrix. 

2. Bent-Pipe Relay 

During long duration, long range exploration, the need may arise to use orbiting relay satellites to extend 
the range of the surface network when surface-based line of sight becomes impractical. As a result, the 
characteristics of the relay satellites deployed can have a profound effect on surface network performance. A 
simple, “bent pipe” satellite system capable only of blindly forwarding packets over each of its communica- 
tions interfaces, for example, could provide differing network and power efficiency than a satellite capable of 
intelligent switching among its interfaces at the packet level. 
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To support modeling of bent pipe relay satellite systems, a simple 
MAC protocol was developed which blindly forwards any received data 
on all possible interfaces to simulate bent-pipe relays. The NASA Switch 
MAC model simply acts as both a dumb flooding switch and a simple 
MAC. In the end station’s node model it will set below the IP ARP, and 
in the satellite switch’s node model it connects all of the point-to-point 
transceivers. This process model is fairly simple. It has no attributes or 
output statistics. 

If a packet comes to the NASA Switch MAC from a higher layer, the 
MAC encapsulates the packet with a MAC header. The header includes a 
unique packet identifier along with the source and destination IDs. Then 
the MAC sends the packet to every transceiver stream to which it is 
connected. 

When a packet comes to the NASA Switch MAC from any lower layer stream the following processing 
occurs. First the MAC checks the packet’s unique ID and verifies that it has not received this packet before. 
If the MAC has previously received the packet then the packet is immediately destroyed. If the packet is 
new, the NASA Switch MAC will then check if this node is the final destination, and if so, it forwards the 
packet to higher layers. If the receiving node is not the final destination it will forward the packet on all 
interfaces except the one from which it received the original packet. 

3. Constant Bit Rate Application 

Many applications which will run over the surface network, such as stream- 
ing multimedia, tolerate moderate packet loss but depend on consistant 
latency and relatively constant data rates over time for proper function- 
ality. To model these applications, a constant bit rate application (CBR) 
was developed to provide unreliable service with packets generated con- 
sist ant ly at a constant rate, 

A custom model was built to simulate CBR traffic such as monitoring 
data and TT&C. Video and voice are assumed to be CBR sources. The 
CBR application is the simplest of all the applications. The sending ap- 
plication sends a packet every x number of seconds so that the “Packet 
Size” and “Data Rate” attributes are true. All of the packet sizes are the 
constant “Packet Size” value specified in the object attributes, and the 
time between packet sends will also remain constant. 

Packets are only sent between the application’s start time and end time. The application’s start time is 
randomly chosen using a uniform distribution to be between the times specified by the attributes, “Earliest 
Start Time” and “Latest Start Time.” The application’s end time is simply determined from the attribute 
“End Time.” The receiving application simply receives the incoming packets and records the appropriate 
statistics, 

4- Reliable File Transfer 

The long distance and delays of space communication often cause problems from existing standard ap- 
plications and protocols used over the internet. Standard OPNET file transfer applications such as FTP 
and HTTP assume TCP reliable transport, which is not feasible over Lunar distances. A simple model of 
CFDP , 15 a file transfer protocol designed for high latency links was created to simulate reliable data transfer, 
CFDP is not modeled in OPNET’s standard library, so a new model needed to be built. 

CFDP is a file transfer protocol which assumes unreliable service from the transport layer. It was designed 
to handle the long delays associated with space communications. The CFDP model was designed to run 
over OPNET’s standard UDP transport layer model. The deferred NACK was the CFDP flavor that was 
used. 



Figure 7. The NASA applica- 
tions process model in OPNET 
modeler. 



Figure 6. The simple MAC pro- 
tocol model used for bent-pipe 
relays. 
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5. Robotic Control 

A simple command/ acknowledgement application was developed to model remote control of robotic mission 
elements. The Robotic Control application is also fairly simple. The basic concept is that the sender will 
send a robotic control message to the receiver. The receiver will receive the message and reply with an 
acknowledgement message. If the sender receives that acknowledgement then the sender will consider the 
message complete and schedule an interrupt for the next robotic control message. If the sender does not 
receive an acknowledgement then the sender will resend the robotic control message, and the cycle will repeat 
itself until either the sender receives an acknowledgement or sender the exhausts the maximum number of 
retries. 

Robot control message sizes, the time between robotic commands, size of acknowledgements, and the 
maximum number of retries are determined by the user-defined attributes. 

C. Statistics 

Statistic collection for the above customized applications was also implemented. During a simulation, statis- 
tics were recorded both for every application stream and for every node. The node statistics represent the 
aggregate totals of the application streams running on the node. 

1. Application Statistics 

The application statistics recorded were: 

• Offered Data Load - The amount of original data this application is trying to send. Control messages 
and resent data are not included in this statistic. The units are in bps. 

• Offered Load - The load this application is offering to the lower layers. This statistic includes control 
messages, new data, and resent data. The units are in bps. 

• Throughput - The amount of data received by the node. The units are in bps. 

• Packets Sent - The total amount of packets sent by this node. The units are packets per second. 

• Packets Received - The total amount of packets received by this node. The units are in packets per 
second. 

• Delay - The amount of time it takes for a transmitted packet to reach its destination. The units are 
in seconds, and it is only recorded at the receiver. 

2. Node Statistics 

The node statistics recorded were: 

• Total Offered Data Load - Sum of the application Offered Data Load. 

• Total Offered Load - Sum of the application Offered Load. 

• Total Throughput - Sum of the application Throughput. 

• Total Packets Sent - Sum of the application Packets Sent. 

• Total Packets Received - Sum of the application Packets Received. 

• Delay - This compilation of the all the application delays. 

VI. Simulation Results 
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Table 3. Simulation statistics for different wireless protocols in a surface network environment. 


Wireless Protocol 

Arrival Probability 

Jitter 

802.11b 

0.458 

0.0502 

802. llg 

0.700 

0.0438 

802.11a 

0.778 

0.0349 


Simulations were carried out to assess the per- 
formance of the 802.11a and 802. llg wireless proto- 
cols in the scenarios described above. The statistics 
were assessed based on average throughput (figure 
8), end-to-end delay between surface-based nodes 
(figure 9), and total data dropped (figure 10 on the 
surface network. 

In figure 8, 802. llg throughput drops slightly be- 
low that of 802.11a, and 802.11b produced the low- 
est average throughput, as expected due to its low 
maximum data rate of 11 Mbps. Both 802. llg and 
802.11a scale their data rates according to the sig- 
nal to noise ratio. 802. llg has a smaller radius of 
54 Mbps coverage than 802.11a, which accounts for 
the reduced throughput. 

Table VI shows statistics collected during simu- 
lations for packet arrival probability (i.e. the proba- 
bility that a packet will not be dropped) and jitter, 
which was calculated as the standard deviation of 
the end-to-end delay. 802.11a had the least packet d 
rate, 802. llg had more packet drops than 802.11a d 



Figure 8. Average throughput on surface-to-surface 
communications links. 

)ps, while 802.11b had the most, due to the lower data 
e to the data rate scaling described above. 



Figure 9. Surface network media access delay for nodes 
on the Lunar surface. 

802.11a and 802. llg performed similarly with respect to media access delay. Because a saturated 802.11 
network will generally experience higher media access delays, 802.11b had the highest delays. For Earth- 
Moon communications, the Earth-Moon backbone link dominates the end-to-end delay experienced by the 
users. While a more efficient routing protocol or media access protocol might be able to reduce delay on 
the surface, the improvements will only carry limited impact for improvement in total end-to-end delay. For 
surface-to-surface communications, however, delays of greater than one second can affect real-time use, and 
routing and media access improvements can greatly impact the user experience. 
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VII. Conclusion 


This paper described modifications to the OP- 
NET simulation tool to support surface communi- 
cations networks for exploration. Simulation of sur- 
face networks provides a simple, inexpensive tool for 
architecture assessment, critical technology and ca- 
pability gap analysis, and protocol evaluation which 
can play a crucial role at any stage in the capability 
and technology development cycles. 

While this simulation tool is capable of model- 
ing surface networks, there are several limitations 
to its fidelity. These limitations occur in three ar- 
eas: physical layer modeling and RF propagation, 
protocols, and routing incompatibilities. 

OPNET is limited at the physical layer for Lu- 
nar and Martian scenarios. In order to achieve re- 
alistic Lunar RF propagation effects, cross channel 
interference modeling, and implementations of mod- 
ulation and coding schemes, OPNET must be aug- 
mented with an external modeling tool. Satellite 

Tool Kit (STK) has been combined with OPNET for physical link modeling for satellite system simulation 
and terrestrial military excercise simulation, but the maturity of the interface is relatively low and may 
not scale well to include the Lunar surface. In addition, the OPNET 802.11 models break down at ranges 
greater than 300 m. Surface network simulation is also limited by use of customized space protocols such as 
CCSDS and the SCPS protocol suite. Models for these protocols are not widely available. Finally, routing 
incompatibilities forced all interfaces in the simulation to run the AODV routing protocol, including fixed 
nodes on wired interfaces such as sensors and instruments, which may have led to sub-optimal performance. 
The next step in the development of high fidelity surface network simulation is to address these issues to 
create enhanced, realistic simulations to assist in the study, development, and evaluation process for surface 
systems. 



Figure 10. Data dropped by wireless network in simu- 
lated scenario. 
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